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PROGRESS IN SOFTWARE ENGINEERING: PART 1 


Over the years, programmers have tended to treat program- 
ming as an “art, involving creative, innovative talents that are 
not properly the subject of a discipline. At the same time, many 
people who are familiar with computer hardware engineering 
claim that computer programming inherently involves no more 
logical complexity than hardware engineering—which is subject 
to a discipline. In fact, there is some good evidence to support this 
view. Gradually the concept of software engineering has evolved, 
to the point where today it claims a substantial and growing body 
of knowledge. As the benefits become recognized, software engi- 
neering will permeate the whole development and modification 
process. Here is the first of two reports on where the field stands 


today. 


Deiwae engineering seeks to impose a meth- 
odology and a discipline on (1) the development 
and modification of software, and (2) the manage- 
ment of software development and modification. 

Several points should be noted in this defini- 
tion. Most authors on the subject limit the subject 
to a methodology for the development of soft- 
ware. We are suggesting here that the continued 
modification of that software also should be a part 
of the subject area. Similarly, many authors limit 
the subject to the activities of designing and con- 
structing software. We are suggesting that the 
management of those activities is also a part of 
the subject area. 

Two questions of course stand out: 

- Can software in fact be engineered? 
- Should software be engineered? 

In addressing these questions, let us consider 
the viewpoints of two leading figures in the field— 
Donald Knuth and Edsger Dijkstra. Both have 
been the recipients of the prestigious ACM Tur- 
ing Award. 

Donald Knuth (Reference 1) argues for the art 
of computer programming. He seeks beauty and 


elegance in programs. He urges trying to achieve 
beautiful solutions to problems. 

What is “beauty” in a computer program? We 
believe that Knuth means gaining an insight into a 
complex problem, grasping all of its essential ele- 
ments and their relationships, and then coming up 
with a clean, crisp, “beautiful” solution. 

A well-known example might help to illustrate 
what is meant. It concerns the case of the mother 
with two small boys and one piece of cake to be 
divided between them. How was she able to di- 
vide that piece of cake, she was asked, so that the 
boys would not argue over who would get the big- 
ger piece. It was easy, she replied. She had one of 
the boys divide the cake and the other boy get the 
first choice. This is indeed a beautiful solution, in 
our opinion. 

But Knuth also seeks “goodness” of programms, 
in addition to beauty. He includes “works cor- 
rectly’ and “not hard to change’ among the char- 
acteristics of goodness. He also asks that programs 
interact gracefully with users, give meaningful er- 
ror messages, and use flexible, non-error-prone in- 
put formats. 
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It seems to us that Knuth is saying program- 
ming is an “art” to the extent that sufficiently 
good solutions are not yeta part of common prac- 
tices. But these “goodness” characteristics might 
very well become a part of common practices and 
a part of a programming discipline. Of course, 
one might argue that even better solutions might 
be sought and that programming will thus always 
remain an art. Programming managers faced with 
deadlines may be reluctant to support such 
searches ad infinitum. 

Kdsger Dijkstra (Reference 2) advocates a dis- 
cipline for mastering complexity in large com- 
puter programs. He proposes an approach for 
handling complexity via the concurrent devel- 
oprnent of the program and its proof of correct- 
ness. His approach includes structured 
programming by stepwise refinement, as well as 
proving the correctness of the program as it is de- 
veloped. We will have more to say about Dij- 
kstra’s views later in this report. Suffice it to say 
here that he advocates a discipline for programm- 
ing and one that is in harmony with software engi- 
neering. 

It seems to us that there is, and there always 
will be, an “art” element to programming. This 
element seeks beautiful solutions to problems. But 
once these solutions have been developed, they 
might well become a part of good programming 
practices. The discipline of “good programming 
practices is necessary for handling problem 
complexity and assuring program correctness. 

It would appear, then, that a discipline of good 
programming practices (in other words, software 
engineering) is needed and is accomplishable. 
Software engineering seeks the basic principles 
that are the fundamentals of good programming 
practice. 


The scope of software engineering 

We participated in a planning session on a soft- 
ware engineering handbook several years ago. 
The planning session was sponsored by the U.S. 
National Bureau of Standards, the National Sci- 
ence Foundation, and the Association for Com- 
puting Machinery. The results are reported in 
Reference 3. NBS has since initiated a project to 
develop such a handbook, in part based upon the 
recommendations of the planning session. 

The planning session included such leading fig- 
ures in programming methodology as Edsger Dij- 
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kstra, Barbara Liskov, and Robert Floyd, and 
practitioners and managers such as Joel Aron, An- 
thony D’Anna, Dennis Fife, Aaron Finerman, 
John Gosden, Harry Larson, Charles Lecht, and 
Daniel Teichroew. The group thus included rep- 
resentatives of both research and production en- 
vironments, and both technical and managerial 
functions. 

This planning session defined the scope of soft- 
ware engineering to include both the technical 
and the managerial aspects. We feel that the defi- 
nition of the subject area made by this group has 
stood up well during the interim. Here are the 
highlights of that definition. 


Software engineering techniques. The scope of 
software engineering technology should apply to 
systems, programs, and data. The techniques 
should apply to the architecture of these elements, 
to their enginecring, to their construction, and to 
their acceptability testing. Special considerations 
should be given to large systems. 


Software engineering management techniques. 
Every bit as important as the software engineer- 
ing techniques are the management techniques 
under which development takes place. For in- 
stance, in its assignment of a tight time schedule 
to a project, management may be in fact making 
the basic architectural decisions for the system. 
The planning session identified some candidate 
first principles for managing software projects, as 
well as the need for a standard project discipline. 

We see some possible modifications to the 
scope of software engineering, as proposed by this 
planning session. The software engineering tech- 
niques should include methodologies for problem 
definition and requirements analysis. Also, the 
methodologies for construction should be en- 
larged to include techniques for the modification 
of systems, programs, and data definitions. Fur- 
ther, techniques for the evaluation of systems, 
programs, and data might be included. 

In the management of system development and 
modification, managers should have an under- 
standing of several important behavior patterns. 
These patterns include staff behavior, project be- 
havior, and program evolution. We will discuss 
these behavior patterns next month. 

We have attended conferences, conference ses- 
sions, and workshops on the subject of software 


engineering. In addition, we have reviewed a sub- 
stantial amount of the technical literature. It is 
apparent to us that there is a tremendous amount 
of work going on in this subject area. Further, it is 
evident that the methodologies are gradually be- 
coming a part of the “good practices” of the com- 
puter field. We discussed some of these 
methodologies in our November and December 
1977 and January 1978 reports. But we also began 
to see the need for one or two “overview reports 
that would show the breadth of what is emerging. 
Hence this report and the one next month. 

Let us look first at what is emerging in the area 
of technical methodologies. 


SOFTWARE ENGINEERING 
METHODS 


There is really too inuch work going on in the 
area of software engineering techniques for us to 
be able to review it in one or two issues. But quite 
a bit of that work is in the early stages of research 
or development. While much of that work is in- 
teresting, it is perhaps too early for us to discuss it; 
we prefer to wait until it is ready for practical ap- 
plication. So we have selected for discussion some 
of the work that most appeals to us and that seems 
to have immediate application. However, the ref- 
erences cited at the end of these two reports point 
to literature that covers much of the whole sub- 
ject area. 


Problem definition area 


The subject area of problem definition and re- 
quirements engineering is really just beginning to 
emerge. We gave an overview of this subject in 
our July 1977 report, which we will summarize 
shortly. 

Ross and Schoman (in Reference 8e) point out 
that the total system development process con- 
sists of a series of steps leading to the solution of a 
problem. In these steps, only once is the problem 
itself stated and the solution justified—and that is 
in the requirements definition phase. Require- 
ments definition deals with why the system is 
needed, what features are needed, and how the 
system is to be constructed, they say. 

They advocate the method of successive refine- 
ment and decomposition. This method considers 
everything relevant at a given point and nothing 
more. The not-yet-relevant decisions are post- 
poned until they are relevant. 
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The authors have been parties to the devel- 
opment of SADT, which stands for Structured 
Analysis and Design Technique. Savy uses a rela- 
tively simple graphic technique with boxes and 
arrows. The boxes represent the system com- 
ponents and the arrows are the interfaces. The 
top level diagram shows the main components of 
the system. Successive diagrams decompose these 
components. While each diagram is relatively 
simple to draw, the technique of problem analysis 
requires a significant effort to learn. It generally 
takes from one to two weeks of classroom train- 
ing, plus on-the-job training, before an analyst 
can begin to do useful work with the methodol- 
ogy, we gather. Further, proficiency comes only 
with experience. It is not a case of just reading the 
manual and then beginning to use the methodol- 
ogy. For more information on sapT, see Refer- 
ence 9. 

The Ispos project at the University of Mich- 
igan, which we discussed in our November 197] 
report, has developed a problem statement lan- 
guage (PSL) and a problem statement analyzer 
(PSA) program, for tackling the area of problem 
definition. Psu is in use by a good number of large 
organizations. For more information, see Retfer- 
ence 6. 

In our July 1977 report, we discussed a sugges- 
ted no-frills program that an organization can use 
to get the requirements right for new application 
systems, based on work that had been done in this 
subject area. Here are the main points of that 
program. 

Recognize the types of errors. Begin to develop 
a list of the errors of omission and commission 
found in requirements statements. These errors 
come to light during the subsequent phases of all 
projects. Classify the errors by type and then start 
making management aware of the list. 

Get user involvement. Hold two-day “require- 
ments sessions’ to set the requirements for each 
new application system. Make sure that key man- 
agers participate. The error list that has been de- 
veloped not only will help to get this 
participation but also will act as a checklist for 
discussion. Users should also participate in the ap- 
propriate inspection sessions. 

Select an approach for handling complexity. 
Functional decomposition (also called successive 
refinement, top-down expansion, or levels of ab- 
straction approach) currently is the favored ap- 


proach for handling complexity. Information 
flow analysis is another approach; it charts the 
flow of information from origin to ultimate use. 
There are also some software tools that help to 
make changes more easily, as complexity causes 
changes in design. 

Use an inspection process. A key element for 
getting the requirements right is the inspection 
process. It involves a two to three hour review 
session at each inspection point in a project. In- 
spections should be performed on requirements, 
specifications, system designs, program designs, 
coding, and testing plans. The informal structured 
walk-through, discussed in our November 1977 
report, is currently popular. Fagan (Reference 7a) 
advocates a more formal approach to inspections. 

Define expected performance. Errors of omis- 
sion and commission will come to light if per- 
formance validation tests are developed for all 
requirements statements. Attempting to develop 
such tests will bring the requirements into clearer 
focus. 

The upshot of the work being done in this area 
of problem definition is that it does involve a dis- 
cipline and further that this discipline is imposed 
throughout the development process. This work 
recognizes that errors of omission and commis- 
sion permeate the requirements statements for al- 
most all computer-based systems. It takes a 
continuing effort to flush them out. 


Architecture, engineering, design 


Mills (in Reference 8b) makes the point that en- 
tirely too much of the programming effort today 
is spent on corrective and adaptive maintenance. 
Corrective maintenance seeks to remove the er- 
rors that should not have been built into the sys- 
tems, and adaptive maintenance seeks to enhance 
the systems to perform additional functions. 
While not all of the adaptive maintenance can be 
avoided, much of it can, Mills implies, if the job 
were done properly from the outset. The key to 
getting programs right, says Mills, is clean, com- 
pelling, rigorous design. He then goes on to pro- 
pose a general approach based on functional 
decomposition. 

If design plays this key a role in getting systems 
and programs right, then one would expect that a 
good amount of software engineering literature 
would address this question. Right? Well, unfor- 
tunately, this is not so. The whole design area, in- 
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cluding overall design (architecture) and the 
more detailed design aimed at goodness of oper- 
ation (engineering), has received very spotty 
treatment. 


Architecture 

As just mentioned, the “architecture” of a sys- 
tem deals with its overall design and general 
structure. Ideally, the system architects seek 
“beautiful” solutions. In practice, computer- 
based systems usually involve so much complexity 
that the architects simply seek solutions that 
will work and that have some goodness 
characteristics. 

Dijkstra (Reference 2) discusses mental tools 
that the system architect can use for handling 
complexity and still come up with a good overall 
design. We discussed Dijkstra’s “levels of ab- 
straction” approach in our June 1974 report. His 
newer work builds on this earlier work and adds 
the proof of correctness concepts. With the levels 
of abstraction approach (or functional decompo- 
sition), one starts with the overall system and then 
tries to identify all of the major components of 
that system. No attempt is made to analyze each 
of the components until all of the top-level parts 
have been identified. Then the architect steps 
down one level and goes through the same sort of 
analysis for each of these top-level parts. By han- 
dling complexity one level at a time, the architect 
not only has a better chance of handling it “right” 
but also has more of a chance of developing a 
“beautiful” solution 

Most of the discussion of this type of approach 
has dealt with the design of programs rather than 
with the design of complete applications or soft- 
ware systems. While the principles would seem to 
be appropriate, we think that much more in- 
vestigation is needed to see how these principles 
can be applied over a wide range of application 
and software systems. 


Engineering 

Engineering involves the “good practices” part 
of solutions. When the engineering is based on a 
theoretical foundation, such as a mathematical 
foundation, it becomes inter-mixed with the ar- 
chitectural process. In general, software engi- 
neering does not yet have a widely accepted 
theoretical foundation. However, next month we 
will discuss the concepts developed by Kenneth 


Kolence of what he calls “software physics.” He 
sees this work providing a theoretical foundation 
for software engineering. 

The American Federation of Information Proc- 
essing Societies (AFIPS) has sponsored some work 
dealing with goodness characteristics of informa- 
tion systems. Their Best Practices Manual on 
Security (Reference 9) provides design guidelines 
plus an extensive checklist of some 900 questions 
relating to security that the system designer 
should consider. A second Best Practices Man- 
ual, on designing for system integrity, is under 
development. 


Design 

The term “design” is a general term used by 
many (including ourselves) to cover both the ar- 
chitectural and the engineering functions. Every 
system, program, and data structure has a “de- 
sign, even if that design has not been explicitly 
planned. The design may be rambling, with a hor- 
ribly involuted control structure, if the builders 
just start building before thinking through the 
design. 

Even in this more catch-all subject area of de- 
sign, the literature and the conference sessions 
have been sparse. Very little has been said or 
written on system and sub-system design 
methodology. 

Freeman and Wasserman (Reference 22) pro- 
vide reprints of 18 key papers on software design 
plus some 100 pages of original material that ex- 
plains software design concepts. This paperback 
book gives an overview of the system and pro- 
gram design process. The design techniques and 
tools that are described apply mainly at the pro- 
gram design level. These include structured pro- 
gramming, decomposing systems into modules, 
and the use of program design languages. More 
books of this nature clearly are needed. 

Peters and Tripp (in Reference 23) compare a 
number of the leading software design methodol- 
ogies. These include structured design (as pro- 
posed by Constantine, Yourdon, and Myers), the 
Michael Jackson method, Warnier’s Logical Con- 
struction of Programs, the META stepwise refine- 
ment method, and the high order software 
method. 

Ben Schneiderman (Reference 10c) catalogs a 
number of approaches to program and data struc- 
ture design and gives a 38-item bibliography for 
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further details. The program design methods in- 
clude: single module programs, linear structures, 
tree structures, level structures, and network 
structures for programs. The data structures that 
he catalogs include: single node, linear, tree, and 
network structures. 

L. C. Carpenter and L. L. Tripp (Reference 11) 
describe a computer program (DECA) that is used 
in conjunction with a top-down dominated design 
methodology. This program organizes, validates, 
and produces documentation depicting the de- 
sign of a software system. It significantly enhances 
the quality of the software design, say the authors. 

We are not saying that these are the only pa- 
pers on design that we have come across. But they 
were the papers that most appealed to us. Fur- 
ther, the selection was very limited. 


Construction and modification 

The situation in the construction subject area is 
far different from what we encountered in the de- 
sign area. In construction, much work has been 
done in the development of tools and techniques. 
Some attention has been paid to construction 
methods that make subsequent modification eas- 
ier. But not much has been reported on modifica- 
tion techniques themselves. 


Construction techniques 


In our November 1977 report, we discussed 
user experiences with a number of programming 
aids marketed by IBM under the name of Im- 
proved Programming Technologies (iprs). These 
methods include top-down development, struc- 
tured programming, chief programmer teams, 
HIPO, pseudo code, development support library, 
structured walk-throughs, and an interactive de- 
bugging facility. All of these seek to impose a dis- 
cipline on the program construction process. As 
we said in that report, “People we talked with 
were genuinely impressed (if not somewhat sur- 
prised) with the gains they had made in their soft- 
ware development process through the use of 
certain 1pTs.” So here is an example of some soft- 
ware engineering methods that are already hav- 
ing an impact on the software development 
process. 

F. T. Baker (in Reference 11) discusses how 
some of these 1PTs were introduced at IBM’s Fed- 
eral Systems Division. While work remains to be 
done on the methodologies, he feels that rsp’s ex- 
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periences have been very positive. Further, he 
feels that the plan that rsp used to introduce these 
techniques was successful and could serve as a 
model for other organizations. 

D. J. Reifer and Stephen Trattner (Reference 
12) provide an extensive glossary of software tools 
and techniques. Some 70 types of tools and tech- 
niques are identified and classified in terms of 
where they can be used in the life cycle of a soft- 
ware system. A 6]-item bibliography then gives 
sources of more detailed information on these 
tools and techniques. This paper in itself gives a 
good idea of the large amount of work that has 
been going into better methods to support the 
construction of computer programs. 

Leon Stucki (in Reference 13), of Boeing Com- 
puter Services, gives a brief position paper on the 
acquisition of software development tools, based 
on experience at his company. A case example is 
presented, based on a lengthy investigation Stucki 
performed, wherein some of the more sophis- 
ticated programming support tools were ana- 
lyzed. But, says Stucki, “Much work remains to be 
done in this area. We are still, for the most part, 
bench marking tools to find their costs and guess- 
ing as to their potential benefits.” 

In our review of construction tools and tech- 
niques discussed in the past year or two, most of 
the attention has been given to some aspect of 
structured programming. 


Structured programming methodology. There 
have been numerous important books on modular 
and structured programming. These include the 
books by Dijkstra (Reference 2), J-D. Warnier 
(Reference 14), Michael Jackson (Reference 15), 
Edward Yourdon (Reference 16), and Glen Myers 
(Reference 17). We will make no attempt to re- 
view these works here, but we have discussed in 
previous reports Dijkstra’s work (June 1974) and 
Warnier’s work (December 1974). 

Peter Neely (Reference 10a) describes a pro- 
gramming discipline that draws heavily on the 
work of Warnier but also acknowledges the work 
of others such as Dijkstra and Jackson. Neely ad- 
vocates the top-down expansion of programs. Ev- 
ery task has a beginning, a middle, and an end, 
where the beginning and the end are executed at 
most once. The middle is typically a loop, and 
consists of a number of tasks. Each of these sub- 
tasks is next decomposed into its beginning, 
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middle, and end. Neely gives some examples of 
how the discipline can be used in practice. And 
then he makes an interesting statement: “The 
only bug that I have encountered in my own pro- 
gramming in the past three years was in one 
(module) in which I did not use structured pro- 
gramming. How many programmers can come 
anywhere near making a statement like that? 


Support of structured programming. “Struc- 
tured programming sounds fine,” some people 
say, “but it involves a lot of changes in method on 
the part of programmers. We have some pretty 
large application systems under development. 
How do we introduce structured programming in 
such situations without wrecking our schedules?” 

V. R. Basili and A. J. Turner (Reference 8a) pro- 
vide one answer to this question that they say has 
worked well for them. It is “iterative enhance- 
ment” of a software system. Trying to use a well 
modularized, top-down approach to building a 
system requires that the problem and its solution 
be well understood, they say. But even if the prob- 
lem is a familiar one, it is often hard to achieve a 
good design on the first try. Design flaws may not 
show up until construction is underway, at which 
time corrections can involve a major effort. 

Their approach starts construction with a 
simple skeletal subset of the problem. This skel- 
etal solution should include a sampling of the key 
aspects of the problem, simple enough to under- 
stand and to build, and which will deliver a usable 
and useful product to the user. Further, this skel- 
etal solution represents only an initial guess at the 
structure of the final solution. In addition to 
choosing the skeletal subset of the problem, the 
builder should develop a project control list of all 
of the things that still must be done. 

Build this skeletal solution, they say, and give 
the outputs to the user. Find out if the design must 
be changed; if so, change it. Since only part of the 
overall problem is being tackled, complexity is 
much less and changes are not too much of a prob- 
lem. 

After the skeletal solution is working satisfac- 
torily, take the next item(s) on the project control 
list and add it (them) to the solution. Repeat the 
process of checking outputs with the users. As the 
system expands, analyze it for structure, modu- 
larity, usability, reliability, and efficiency, they 
say. These analyses may require that new tasks be 


added to the project control task tist. Further, any 
difficulty in design, coding, or debugging a modi- 
fication should signal the need for redesign or re- 
coding of existing components. While this “do 
over’ work may seem discouraging, most of it 
tends to occur during the early stages. As the iter- 
ations converge to the full solution, fewer and 
fewer modifications will need be made. 

This approach of Basili and Turner is in con- 
trast to other iterative approaches. The most 
commonly advocated iterative approach we are 
aware of might be termed “iterative refinement, ” 
where the entire system is initially built and then 
iteratively refined. It would appear that changes 
would be much easier and less expensive to make 
with Basili and Turner’s method. 

(Parenthetically, it was pointed out to us that 
this approach of Basili and Turner is an effective 
way to get user involvement, particularly when 
the problem and its solution are not well under- 
stood. Users usually can deal better with concrete 
system outputs than with abstractions or with a 
myriad of system details.) 

R. J. Cunningham and C. G. Pugh (Reference 
10c) discuss a software system they have devel- 
oped (GLIDE) to support structured programming. 
It encourages development by successive refine- 
ment by allowing the builder to delay the defini- 
tion of a section of code which need not be 
defined at the present stage of the program’s de- 
velopment. The package provides a text editor 
for making changes to the program, and it auto- 
matically checks for changes that are then needed 
in interfaces to other sections of code. An in- 
complete program may be compiled and exe- 
cuted. And if a refinement proves unsuitable, a 
return can be made to the earlier version since 
both the original and the revised versions are 
retained. 


Other types of tools. Much work is going on in 
the development of new programming languages 
for improving the programming function. But the 
use of new programming languages is something 
that is usually carefully controlled in many data 
processing shops. The existing “installation stand- 
ard” programming languages, such as CoBOL and 
pL/1, may not be the best languages possible for 
structured programming, but they can be used. 
Future languages, or future generations of these 
two languages, may be much more appropriate 
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for structured programming, due to the research 
that is going on. 

Similar statements can be made of operating 
systems. There is a lot of research and devel- 
opment work going on in operating system fea- 
tures and characteristics. But again, most 
programmers have no option on the operating 
systems they will use. 


Other types of techniques. Many of the types 
of construction techniques that are a part of soft- 
ware engineering ere listed in Reference 3. These 
include sorting techniques, data compression, 
searching, validation, segmentation, hashing, and 
sO ON. 

Gilb and Weinberg, in Reference 18, discuss 
the subject of humanized input systems that, in 
Knuth’s words, interact gracefully with the hu- 
man users. Special attention is paid by the authors 
to the needs of the data entry specialists (the “key 
punch girls”), in order to make their jobe more 
humanized. Attention is also paid to the newer 
systems where on-line data entry is performed 
throughout the organization, as a part of regular 
operations. 


Modification techniques 


The modification of information systems is of- 
ten considered to be a “bad” thing. When modifi- 
cation is needed to fix errors of omission or 
commission in the problem definition or the 
building process, then it is bad. But when modifi- 
cation is used to enhance a system, we do not see 
it as necessarily bad. 

Mills (Reference 8b) argues for better devel- 
opment procedures in order to reduce the need 
for maintenance. “In only 25 years, some 75 per- 
cent of data processing personnel are already 
taken up with maintenance, not development,” 
he says. One reason for the magnitude of this 
maintenance effort is that the systems are main- 
tained for an indefinite period of time after they 
have been developed. So a fraction of each devel- 
opment staff must be converted to maintenance. 
If 20 percent of each staff must be converted to 
maintenance every two years, says Mills, then at 
the end of 12 years almost 75% of the total staff 
time will be spent on maintenance—and that is 
just about what the actual situation is, he adds. 

The other major reason for the high mainte- 
nance factor is that it has turned out to be more 


difficult to develop “good” systems than was com- 
monly supposed. By “good,” Mills refers to both 
correctness and capability. So a large amount of 
staff time is needed to fix software that could have 
been built correctly at the outset. 

(But the following reasonable question has 
been posed, in connection with Mills’ point. Con- 
sidering the newness of the field and the number 
of “self-taught” programmers and analysts, is it 
reasonable to expect that most software should 
have been built correctly ?) 

As mentioned earlier in this report, Mills ar- 
gues for cleaner, more rigorous design as the main 
means for reducing this large maintenance factor. 
Good design would eliminate much of the correc- 
tive maintenance. And by better identifying what 
the systems must perform, at least some portion of 
the adaptive maintenance may be eliminated. 

One cannot argue with Mills on the need for 
better design and construction methodologies, for 
reducing the need for maintenance. At the same 
time, some adaptive maintenance—more com- 
monly called enhancement—will continue to be 
needed. We think that methods for more efficient 
maintenance are now needed and will continue to 
be needed. 

In our search of the literature, however, we did 
not come across any papers that addressed this 
subject. 

In our June 1972 issue, we described the devel- 
opment methods that Copley Computer Services, 
Inc., of San Diego, California, began using some 
years back. This company switched completely to 
on-line program development, after they in- 
stalled a DECsystem-10. With this plus some of 
the other procedures described in our report, they 
soon turned the whole maintenance picture 
around. Where before, with batch development 
methods, they were spending some 80 percent of 
staff time on maintenance and 20 percent on de- 
velopment, with the new procedures these per- 
centages were reversed. 

In our report last month, on data dictionaries, 
we pointed out that some dictionaries provide 
both production and test status. Maintenance can 
be performed on data definitions in the test status. 
Only when the changes have been satisfactorily 
checked out need the new data definitions be 
moved into production status. 

As we say, we think much more attention 
should be paid to tools and techniques for sup- 
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porting system, program, and data definition 
maintenance. 


Quality assurance 

There are many aspects of quality assurance for 
computer programs, but the prime aspect is, of 
course, program correctness. As with physical 
products, it is recognized that quality cannot be 
“tested into” computer programs. The programs 
have to be built right to begin with. Testing or any 
other form of checking or inspection only pro- 
vides a measure of how well the building job has 
been done. 

We will discuss three methods of checking sys- 
tems, programs, and data definitions, to measure 
their quality. These methods are: inspections, 
testing, and audits. Following this, we will give a 
short discussion of the proof of correctness con- 
cept. From the standpoint of building quality into 
computer programs, probably the area of major 
interest today is the “proof of correctness” meth- 
odology. This discipline seeks to develop the 
proof that a program is correct concurrently with 
the development of the program itself. The 
method is still largely in the research and devel- 
opment stage but we feel that data processing 
management should be aware of it. 

It should be mentioned here that quality assur- 
ance by checking is very closely related to the 
subject of evaluation, which we will discuss next 
month. 


Inspections 


There are a number of ways in current use by 
which computer programs are inspected for cor- 
rectness during the development process. As far 
as we can tell, though, most of the attention is 
being given to two types of informal inspections 
and one type of more formal inspection. 


Informal inspection methods. Probably the 
most widely used of the informal inspection 
methods is the structured walk-through, marketed 
by IBM (Reference 19). We discussed some user 
experiences with this method in our November 
1977 report; in general, the users we have talked 
to have been very happy with the method. 

In a structured walk-through, a programmer, 
say, describes his program design and his code toa 
small, selected group of other programmers. He 
provides copies of the documentation to the 


group members and then “walks through” the 
logic of the program. The group raises questions, 
points out inconsistencies, and so on, in the course 
of the meeting. The programmer is then expected 
to consider all of the points raised and to refine 
the design and/or code as required. 

Edward Yourdon (in Reference 13) has ob- 
served that the structured walk-through is per- 
haps the best way to introduce other 
programming productvity techniques. In Your- 
don’s words, “If a project manager establishes an 
environment of exposing everyone's code to pub- 
lic discussion, then he will ensure that a relatively 
uniform version of top-down implementation, 
_ structured design, and structured programming 
can be implemented later on.” 

Another type of informal inspection is that ad- 
vocated by Gerald Weinberg in his popular book, 
The Psychology of Computer Programming (Ref- 
erence 20). Weinberg urges the use of “egoless 
programming’ and “‘self-adaptive” teams; we dis- 
cussed his concepts in our May 1974 report. Pro- 
grammers are organized in loosely structured 
teams; the team leader of the moment is the per- 
son with the most capability in the function that 
the team is currently working on. Further, each 
programmer submits blocks of code to the other 
team members, for them to read. The team mem- 
bers recognize that everyone makes mistakes— 
and that, on any given day, a person can make a 
horrible number of mistakes. Also, the team mem- 
bers look for better ways of doing things. The re- 
sulting programs are thus rightfully team efforts. 
A team member does not view a set of programs 
that he has worked on as “my” programs but 
rather as “our” programs. 

In both of these types of informal inspections, 
the conduct of the inspections is left pretty much 
in the hands of the participants. Formal in- 
spections, on the other hand, make use of a well- 
defined methodology. 

Formal inspections. M. E. Fagan (in Reference 
7) has described a formal inspection method that 
he has helped develop and which he claims is 
more effective than structured walk-throughs. 
We discussed his approach in our July 1977 re- 
port. A walk-through is just an educational proc- 
ess, he says; further, the participants tend to get 
sidetracked into discussing design alternatives, 
and the process is not self-improving. He seeks to 
correct these shortcomings. 
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Fagan’s formal inspection method has five 
parts. (1) First is a short overview of the work to 
be inspected, presented by the analyst or designer 
who did the work. This is the educational, famil- 
iarization step. (2) Next, each of the inspection 
team participants is given copies of the documen- 
tation and is expected to do “homework” on it, to 
gain understanding. While some errors may be 
caught in this step, this is not the aim of the step. 
(3) The third step is the inspection meeting itself. 
The goal of the meeting is to find errors. The mod- 
erator of the meeting must not let the discussion 
get sidetracked into, say, considering alternative 
designs. Just find the errors, don’t try to solve 
them, says Fagan. Following the meeting, the 
moderator is expected to write up an inspection 
report, listing all of the errors. (4) The next step is 
to rework the work, to get rid of the errors. (5) Fi- 
nally, at least the moderator (and perhaps the 
whole team) must perform a follow-up to see that 
all fixes have been made and made properly. 

Over a period of time, a checklist of error types 
can be developed from the inspection reports. 
The list should indicate their relative frequency 
and their severity. Also, procedures on how to 
look for the errors should evolve, with particular 
attention paid to the most frequently occurring 
and the most severe error types. The checklist and 
these procedures can be used in the inspection 
meetings themselves, as well as by the individual 
analysts and programmers to help them do their 
jobs better. 

The inspection team should be a small one, says 
Fagan, with perhaps four people. The moderator 
is the key person. He or she should be competent 
in the particular application being reviewed. The 
moderator must keep the inspection process mov- 
ing along and not let it get sidetracked. 

These then are the inspection methods that 
seem, in our opinion, to be attracting the most at- 
tention today. They seek to remove errors and im- 
prove design during the construction process. But 
they do this by checking the work of the individ- 


ual analyst or programmer. 


Testing 


Quality assurance in “conventional” pro- 
gramming seems to be based on the concept: 
“program as best you can and then test the dick- 
ens out of it.” Testing has thus been a basic part of 
the programming function since the beginning 


days of computers. One would suppose that test- 
ing would be fairly well understood by now. But 
this is just not so, we are advised. It is still pretty 
much a hit-or-miss affair. Even worse, it has not 
been studied deeply and not much technical liter- 
ature has been written on it. 

In our research for this report, we did not come 
across any literature which was cited as the 
“bible” on testing. Apparently that book or paper 
is still to be written. 

But still, there is some literature on the subject. 
R. D. Hartwick (in Reference 13) discusses the 
subject of test planning. He covers test objectives, 
test planning and organization, error sources and 
detection methods, selection of test methodology, 
and test standards. He presents two tables on er- 
ror categories, indicating the number of errors 
found in 11 projects, the severity of those errors, 
and the detection methods that were used for lo- 
cating those errors. While this probably would be 
classified as an overview paper, it does provide 
guidance on how to approach the testing activity. 

The Transactions on Software Engineering, 
published by the Computer Society of the In- 
stitute of Electrical and Electronic Engineers 
(Reference 8), frequently publishes papers on 
testing. The September 1976 issue, for instance, 
includes five papers on current research areas in 
software testing. In his editorial, the guest editor, 
Leon Stucki, says “Despite all of the software en- 
gineering rhetoric, it is really quite remarkable 
that we know so little about software testing. . . it 
is (my) hope that this set of papers might generate 
a greater motivation for research into many of the 
still unanswered questions relating to software 
testing.” 

The upshot is, then, that in this overview of the 
subject of software engineering, we are unable to 
direct you to definitive information on the subject 
of software testing. Like problem definition and 
design, it is a subject area that has received all too 
little attention. 


Auditing of software 


In March 1977, the U. S. National Bureau of 
Standards and the General Accounting Office 
jointly sponsored a working conference on the au- 
dit and evaluation of computer security. Refer- 
ence 3b reports the results of that conference. 
While the conference topic concerned computer 
security, in point of fact much of the discussion 
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dealt with the broader subject of audit and eval- 
uation of computer software. The results of the 
conference will be used by a federal information 
processing system task group on computer system 
security to develop guidelines for federal 
agencies. 

The conference had ten working panels, each 
addressing an aspect of the subject. Of the ten, we 
will single out two for discussion here. 


The audit of program integrity. Program in- 
tegrity was defined to be the characteristic that a 
program does what its specifications say it should 
do, and should do nothing else. But the discussion 
pointed out that this definition could be chal- 
lenged; instead of “specifications,” perhaps “re- 
quirements’ would be more appropriate—or 
perhaps better yet, “mission.” In other words, 
what defines what the program should do? It 
might be easier or more practical to audit the pro- 
gram against its specifications, but more mean- 
ingful to audit it against its requirements or 
mission. 

Perhaps the major conclusion of this working 
panel was that program integrity has to be built 
into the program from the outset; it cannot be 
added as an after-thought. All that an audit can do 
is to see that program integrity considerations are 
a part of the regular program development proc- 
ess. So, as we see it, program integrity consid- 
erations should be a part of the body of 
knowledge of software engineering. 

The working panel identified six types of 
threats that can challenge the integrity of a com- 
puter-based system. From high to low severity, 
these are: irrational attack, conspiracy by a team, 
a browser through the files, a user who stumbles 
upon something important, human errors, and 
natural failures. A program with a high degree of 
integrity should do what it is supposed to do, and 
nothing else, when subjected to such threats. 

How can program integrity be achieved or en- 
hanced? The panel identified three general cate- 
gories of methods. Program correctness can be 
measured by static evaluations, such as reviews, 
inspections, and proof of correctness, and/or by 
dynamic evaluations such as by running the pro- 
gram to see how it works or by checking compiler 
results. Program robustness can be achieved by 
on-going testing after installation, by on-going 
monitoring and control, and by the use of planned 
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redundancy. Finally, trustworthiness in the pro- 
gram can be enhanced by the use of skilled people 
in the development process, by the use of good 
development practices, and by the use of good 
tools to aid in development. 

In short, this working panel identified a number 
of tools, techniques, and methods that can be used 
to promote program integrity. But the panel 
pointed out that integrity must be engineered into 
the software. 


Auditing under different system  environ- 
ments. This working panel concluded that the en- 
vironment under which a system will operate 
must be identified and then steps must be taken to 
control that environment. Further, this control of 
the environment must be engineered into the sys- 
tem from the beginning. Auditing should verify 
that this control of the environment is being con- 
sidered during the development process. 

The panel identified a number of key factors 
that characterize the environment. These include 
the degree of resource sharing, the type of service 
(batch, interactive), centralized versus dis- 
tributed, local or remote user access, the sensi- 
tivity of the information in the system, the threats 
that the system is likely to face, and so on. 

There are many tools and techniques available 
for controlling the environment and providing 
protection, said the panel. A number of these 
were listed, including site perimeter controls, 
backup systems, audit trails, change control 
procedures, and so on. 

Furthermore, said the panel, audit checklists 
can and should be developed to help the auditors 
determine how effectively environment con- 
trols have been engineered into the overall system 
implementations. 

As we see it, auditing is one more method, 
along with inspections and testing, for checking 
to see whether good software engineering prac- 
tices are being followed. 


Proving correctness 


In his review of Dijkstra’s book, A Discipline of 
Programming, W. C. McGee (Reference 21) has 
this to say: “Anyone who has ever been associated 
with the development of a large or complex pro- 
gram is familiar with the tendency for such pro- 
grams eventually to become so large and so 
complex that no one individual really understands 
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them or can reliably predict how they will behave 
in some previously unencountered situation ... 
Such programs are examples of what E. W. Dij- 
kstra calls unmastered complexity ... When (this) 
occurs in human artifacts such as computer pro- 
grams, it is unconscionable. ” 

To attack the problem of mastering complexity 
in large programs, Dijkstra seeks to develop the 
program and its proof of correctness con- 
currently, says McGee. In fact, the act of proving 
the correctness often suggests the form the pro- 
gram should take, derived in an almost mechani- 
cal manner. 

What is the “proof of correctness” concept? 
David Gries, in Reference 8b, has presented an in- 
teresting overview of it. We will give our under- 
standing of Gries’ thoughts. 

To illustrate the concepts involved, Gries uses 
an example of writing a program to justify lines of 
type—that is, to even out the right hand margins. 
Extra blanks are to be inserted between pairs of 
words so that the last character of the last word in 
a line appears in the last column of the line. 

But, as always, there are complexities. So that 
the spacing appears even, the number of blanks 
between different pairs of words on one line 
should differ by no more than one. Also, to make 
the extra blanks less evident to the reader, blanks 
will tend to be inserted toward the left of even 
numbered lines, say, and toward the right on odd 
numbered lines. 

The problem is, then, given the column num- 
bers where the words begin on the unjustified line, 
to find the column numbers where the words will 
begin on the justified line. 

In conventional programming, says Gries, the 
programmer starts out by naming the procedure 
(“justify”) and the variables, and then proceeds to 
develop an algorithm to do the job. But this is not 
sufficiently precise to insure a correct program, 
he now has come to see. 

With the proof of correctness method, the pro- 
grammer must define the pre- and post-conditions 
for the program. The pre-condition is the asser- 
tions about the input. Gries identifies two such as- 
sertions. One, the extra spaces that are to be 
inserted must be equal to or greater than zero; no 
negative spaces can be inserted. Two, the column 
numbers of the beginning of the words on the line 
are equal to the initial column numbers for all of 
the words on the line. 
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If these assertions seem rather trivial and ob- 
vious, Gries points out that it took him several ite- 
rations to develop the assertions for the program. 
And Harlan Mills, at the Software Engineering 
Conference held in San Francisco in October 
1976, says that a proof of correctness consists of 
the programmer making a number of assertions, 
for each of which he could justifiably say to an- 
other programmer, “Now that is obvious, isn't 
it?” 

Next Gries makes assertions about the post- 
condition, the output. These assertions say, in 
general, that the extra blanks will be inserted be- 
tween the first and last words of the line. Again, 
there can be no negative blanks. And the blank 
spaces between words to the left of word “t” (a 
word falling between the first and last words) are 
defined differently from the blank spaces to the 
right of word “t.” 

These assertions provide understandable, pre- 
cise specifications for the algorithm, but not in so 
much detail that chaos results, says Gries. With 
the understanding of the pre- and post-conditions, 
he then makes his first attempt to write the al- 
gorithm—a function that defines the blanks for the 
word pairs to the left of word “t” and for the word 
pairs to the right of word “t.” 

While our description probably has not done 
justice to the concepts presented, we hope it does 
give an idea of the mental processes involved. 
Gries’ proof of correctness really is just getting 


under way at this point, and the interested reader 
is referred to his paper for the details. 

As “obvious” as the above assertions might 
seem to be, they surely are obvious only in hind- 
sight (to the programmer who developed them) or 
when someone else has already developed them. 
The hardest part of writing this algorithm was not 
the programming itself, says Gries, but rather it 
was developing the specifications, the assertions. 

Hopefully, this brief discussion has given some 
“feel” of the proof of correctness methodology 
that is now in the research and development 
stage. As we said earlier, proof of correctness is 
perhaps the area of major interest among re- 
searchers working on the problem of quality as- 
surance for computer programs. 


Next month 


Next month we will continue our overview of 
the state of software engineering. We will discuss 
evaluation methods, which are a part of the soft- 
ware engineering methodology. We will then get 
into a discussion of software engineering manage- 
ment methods. As pointed out earlier in this re- 
port, some people we have talked to feel that 
while the software engineering methods may be 
necessary for the development of good software, 
they certainly are not sufficient for achieving that 
end. The management practices under which the 
development is carried on also play a major role. 
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